Multi-platform and multi-application tasks require heavy message exchanges between the platforms or applications. One aspect of the heavy message traffic is message queuing. MQSeries is a method of message queuing that enables disparate applications to communicate with one another across a network of disparate components, such as processors, systems, subsystems, and communications protocols. It provides a consistent application program interface (API) or set of application program interfaces across all of the platforms.
Queuing means that the program-to-program communication is indirect communication, where the end user or programmer specifies a target queue name rather then a target application name. In IBM MQSeries message queuing the application programs communicate by sending messages through respective Message Queue Interfaces, and MQSeries MQ objects, over a network.
A further aspect of queuing is that the end user or programmer does not have to worry about the target application being busy, down, or otherwise unavailable. This is because the program sends messages to a queue that is associated with the application rather then to the application itself, and the MQSeries API takes care of transport to the target application, even including starting the target application if necessary.
MQSeries Message Queuing includes a Message Queue Manager (MQM). The MQM provides a Message Queuing Interface (MQI) by issuing API calls. For example, the API MQPUT puts a message on a queue to be read by another program using the API MQGET. In MQSeries message queuing an application program issues a PUT to place the message in a first or outgoing queue, addressed to application program, via a channel (if the applications are on different platforms). The Application program issues an MQGET to receive the message in its queue.
The message queuing manager manages the message queues for application programs and provides an application program interface, the message queue interface. The queue manager preferably uses existing networking facilities to transfer messages between applications (and platforms). In interfacing with DBMS's and databases, the message queue interface coordinates updates to databases, using a two phase commit process. In this regard, “gets” and “puts” to and from queues are committed together with SQL updates, or backed out, if necessary.
Messages can be segmented or grouped, that is, the Message Queuing Interface segments messages and re-assembles them, and also groups small messages together. This segmenting and grouping capability minimizes network overhead. Segmenting is used when the message does not fit into a queue, for reassembly at the receiver MQI (message queuing interface). By way of contrast, in grouping, several small messages from one process to another single process can be grouped together for transmission. This serves to reduce network overhead.
Message queuing messages can be characterized as persistent and non-persistent. A persistent message must be delivered under any circumstances, while a non-persistent message need not be delivered if not delivered by its expiration date.
The queue manager uses queue objects, process definition objects, and channel objects, as well as platform specific objects, such as buffer pool objects, and user space objects to accomplish message queuing. In this context, a channel object, that is, a connection, is a logical communications link. The queue manager supports message channel objects and message queuing interface channel objects. A message channel object connects two queue managers via message channel agents. Typically, a message channel is unidirectional, and has two channel agents, a sender and a receiver, and a communications protocol. The message channel agent (MCA) is a program that transfers messages from a transmission queue to a communications link, and from the communications link into a target queue. For bidirectional communications, it is necessary to define channel pairs consisting of a sender and a receiver.
The other type of channel object, a Message Queue Interface (MQI) channel object, connects an MQSeries client to a queue manager in its server machine. An MQI channel is bidirectional.
A queue manager is started by commands to run the message queue manager (runmqsc), define the local queue (“define qlocal(‘QUEUENAME’)”), define objects and attributes of the local queues created by the “runmqsc” command (“mydefs”), modify or change the local queue (“alter qmgr”), and close the queue (“end”).
Generally, in a client-server architecture, the queue manager resides on the server, and is shared by all of the clients. Thus, all of the MQSeries objects, such as queues, are in the server. However, an MQ server can be both a client and a server, with intra-platform, inter-process queues. To be noted is that MQSeries distinguishes between clients and servers. For example, MQSeries, when installed on a distributed platform, can be a client, a server, or both. Moreover, local clients may have a local queue manager. Slim clients do not have a local queue manager, while fat clients do have local queue manager. In the case of mobile clients where the connection between client and server may not always exist, it is advantageous for the local client to be a fat client with a local queue manager.
In a typical MQSeries client-server connection, all of the clients use queue managers on the server machine. When the client puts a message on the queue, the message ultimately has to be read and processed by a program on the server. The reading program can be started when the server starts, or the queue manager can start it by using an MQSeries triggering mechanism.
In MQSeries, by way of exemplification, the client sends a request by issuing five API calls:    1. A message queue connect API call, as MQCONN, to connect to the queue manager in the server.    2. A message queue open API call, as MQOPEN, to open the message queue QS1 for output.    3. A message queue put API call, as MQPUT, to put a message in the queue (there may be many messages in the queue).    4. A message queue close API call, as MQCLOSE, to close the queue QS1.    5. A message queue disconnect API call, as MQDISC, to disconnect from the queue manager.
The MQSeries client that runs in the client machine processes API calls and routes them to the machine defined in the environment variable.
The server uses at least five queue manager objects to receive a request. These include a server connection channel, a local queue into which the clients place their messages, an initiation queue into which the queue manager puts a trigger message when a request for the queue arrives, a process definition object that contains the name of the program to be started when the trigger event occurs, and one or more queues into which the server program, puts the reply message.
In the server machine two programs have to be started to enable message queuing, the listener, and the trigger monitor. The listener listens for messages and puts them on the queue. Since the queue is triggered, the message queue manager puts a trigger message on the trigger queue each time a message is put on the queue. When a process is placed on the trigger queue, the trigger monitor starts the program to define in the process.
The server program connects to the queue manager, opens the queue and issues a message queue get, MQGET, to read the message. After processing a request, the server puts a reply on the specific reply queue for the client. The server does this by opening up the output queue and issuing a message queue put, MQPUT API. The client knows the name of its input queue, and issues a message queue get, MQGET API to receive the reply.
An application program, whether on the client or on the server, talks directly to its local queue manager. The queue manager typically resides in the same processor or domain as the program itself. The program uses the Message Queuing Interface (MQI), where the Message Queuing Interface (MQI) is a set of API calls that request services from the queue manager.
The API's provide for connection to a queue manager, disconnection from a queue manager, opening a specific queue, closing a specific queue, putting a message on a queue, getting a message from a queue, inquiring of the properties of an object, setting the properties of an object, binding, beginning a unit of work, committing a unit of work, and backing out. Also, API's can be combined, as into one API to open a queue, put on a message on the opened queue, and close the queue. However, even with this expedient of connections, as queues and channels, when a connection between a client and its server is broken, no API calls can be executed by the client without reestablishing the connection, since all objects reside on the server.
As with any other type of connection (i.e. database or socket), there is overhead associated with setup and initialization of message queuing connections. This overhead includes the time expended in establishing and re-establishing connections. What is needed is a mechanism that avoids the overhead associated with making and breaking of connections while keeping connections alive and reusable by many clients.